Node / mirrors / RTNode-HeltecV4 / files / MICRORETICULUM_BUGS.md

Displaying Rendered • View raw • Download

Several locations in T383838Transport.cpp retrieve T383838LinkEntry or T383838DestinationEntry values from T383838std::map containers by copy instead of by reference. Subsequent mutations (setting T383838_validated, updating T383838_timestamp) only affect the local copy — the actual map entry is never updated.

This is a Python→C++ porting issue: in Python, T383838dict[key] returns a reference to the value, so T383838transport.link_table[link_id][0] = time.time() mutates the dict entry in place. In C++, T383838(*iter).second returns a copy when assigned to a non-reference variable.

File: T383838Transport.cpp, LRPROOF handling section

T282828

Te6edf3LinkEntry Te6edf3link_entry Tff7b72= Tb4b4b4(Tff7b72*Te6edf3_link_tableTb4b4b4.Te6edf3findTb4b4b4(Te6edf3packetTb4b4b4.Te6edf3destination_hashTb4b4b4(Tb4b4b4)Tb4b4b4)Tb4b4b4)Tb4b4b4.Te6edf3secondTb4b4b4; T8b949e// COPY

T8b949e// ... later:

Te6edf3link_entryTb4b4b4.Te6edf3_validated Tff7b72= Tffa657trueTb4b4b4; T8b949e// Only updates local copy

Impact: The link_table entry's T383838_validated stays T383838false. The culling code in T383838jobs() checks:

T282828

Tff7b72if Tb4b4b4(Te6edf3link_entryTb4b4b4.Te6edf3_validatedTb4b4b4) Tb4b4b4{

Tff7b72if Tb4b4b4(Te6edf3OSTff7b72:Tff7b72:Te6edf3timeTb4b4b4(Tb4b4b4) Tff7b72> Tb4b4b4(Te6edf3link_entryTb4b4b4.Te6edf3_timestamp Tff7b72+ Te6edf3LINK_TIMEOUTTb4b4b4)Tb4b4b4) Tb4b4b4{ Tb4b4b4.Tb4b4b4.Tb4b4b4. Tb4b4b4} T8b949e// 15 minutes

Tb4b4b4} Tff7b72else Tb4b4b4{

Tff7b72if Tb4b4b4(Te6edf3OSTff7b72:Tff7b72:Te6edf3timeTb4b4b4(Tb4b4b4) Tff7b72> Te6edf3link_entryTb4b4b4.Te6edf3_proof_timeoutTb4b4b4) Tb4b4b4{ Tb4b4b4.Tb4b4b4.Tb4b4b4. Tb4b4b4} T8b949e// 6-18 seconds

Tb4b4b4}

Since T383838_validated is never set to T383838true, the entry is culled at T383838proof_timeout (6 × hops = 6–18 seconds) instead of T383838LINK_TIMEOUT (15 minutes). All subsequent link data packets (resource chunks, keepalives, etc.) are silently dropped once the entry is removed.

Symptom: Resource transfers start successfully but fail after a few seconds. Link establishes, some data transfers, then all traffic stops. Affects both directions.

Fix: Change to reference:

T282828

Te6edf3LinkEntryTff7b72& Te6edf3link_entry Tff7b72= Tb4b4b4(Tff7b72*Te6edf3_link_tableTb4b4b4.Te6edf3findTb4b4b4(Te6edf3packetTb4b4b4.Te6edf3destination_hashTb4b4b4(Tb4b4b4)Tb4b4b4)Tb4b4b4)Tb4b4b4.Te6edf3secondTb4b4b4;

File: T383838Transport.cpp, link transport handling section

T282828

Te6edf3LinkEntry Te6edf3link_entry Tff7b72= Tb4b4b4(Tff7b72*Te6edf3link_iterTb4b4b4)Tb4b4b4.Te6edf3secondTb4b4b4; T8b949e// COPY

T8b949e// ... later:

Te6edf3link_entryTb4b4b4.Te6edf3_timestamp Tff7b72= Te6edf3OSTff7b72:Tff7b72:Te6edf3timeTb4b4b4(Tb4b4b4)Tb4b4b4; T8b949e// Only updates local copy

Impact: Even with Bug 1a fixed, the linktable entry's T383838_timestamp is set once (at LINKREQUEST time) and never refreshed during ongoing link data forwarding. For long-running transfers exceeding T383838LINK_TIMEOUT (KEEPALIVE=360s, STALETIME=720s, LINK_TIMEOUT=900s = 15 minutes), the entry is eventually culled and the transfer fails.

Fix: Change to reference:

T282828

Te6edf3LinkEntryTff7b72& Te6edf3link_entry Tff7b72= Tb4b4b4(Tff7b72*Te6edf3link_iterTb4b4b4)Tb4b4b4.Te6edf3secondTb4b4b4;

File: T383838Transport.cpp, inbound transport forwarding (HEADER_2 packets where we are the designated next-hop)

T282828

Te6edf3DestinationEntry Te6edf3destination_entry Tff7b72= Tb4b4b4(Tff7b72*Te6edf3destination_iterTb4b4b4)Tb4b4b4.Te6edf3secondTb4b4b4; T8b949e// COPY

T8b949e// ... later:

Te6edf3destination_entryTb4b4b4.Te6edf3_timestamp Tff7b72= Te6edf3OSTff7b72:Tff7b72:Te6edf3timeTb4b4b4(Tb4b4b4)Tb4b4b4; T8b949e// Only updates local copy

Impact: Path timestamps are never refreshed when packets are actively being forwarded along that path. Paths could be culled while still in active use, though the timeout is typically long enough (DESTINATIONTIMEOUT) that this is less likely to cause issues than the linktable bugs.

Fix: Change to reference:

T282828

Te6edf3DestinationEntryTff7b72& Te6edf3destination_entry Tff7b72= Tb4b4b4(Tff7b72*Te6edf3destination_iterTb4b4b4)Tb4b4b4.Te6edf3secondTb4b4b4;

File: T383838Transport.cpp, T383838outbound() method

T282828

Te6edf3DestinationEntry Te6edf3destination_entry Tff7b72= Tb4b4b4(Tff7b72*Te6edf3_destination_tableTb4b4b4.Te6edf3findTb4b4b4(Te6edf3packetTb4b4b4.Te6edf3destination_hashTb4b4b4(Tb4b4b4)Tb4b4b4)Tb4b4b4)Tb4b4b4.Te6edf3secondTb4b4b4; T8b949e// COPY

T8b949e// ... later:

Te6edf3destination_entryTb4b4b4.Te6edf3_timestamp Tff7b72= Te6edf3OSTff7b72:Tff7b72:Te6edf3timeTb4b4b4(Tb4b4b4)Tb4b4b4; T8b949e// Only updates local copy

Impact: Same as 1c — outbound path forwarding never refreshes the path timestamp.

Fix: Change to reference:

T282828

Te6edf3DestinationEntryTff7b72& Te6edf3destination_entry Tff7b72= Tb4b4b4(Tff7b72*Te6edf3_destination_tableTb4b4b4.Te6edf3findTb4b4b4(Te6edf3packetTb4b4b4.Te6edf3destination_hashTb4b4b4(Tb4b4b4)Tb4b4b4)Tb4b4b4)Tb4b4b4.Te6edf3secondTb4b4b4;

Search for the pattern: assignments from map iterators without T383838&:

T282828

Any line matching T383838SomeEntry variable_name = (*iter).second; (without T383838& after the type) that later mutates a field of T383838variable_name is a bug.

The following locations also copy entries but only read from them (no mutation). They are not bugs but are unnecessarily copying large structs:

• T383838for_local_client check: T383838LinkEntry link_entry = (*link_iter).second; — read-only, safe

• T383838for_local_client check: T383838DestinationEntry destination_entry = (*destination_iter).second; — read-only, safe

• T383838proof_for_local_client check: T383838ReverseEntry reverse_entry = (*reverse_iter).second; — read-only, safe

• Several T383838DestinationEntry copies in T383838has_path(), T383838hops_to(), T383838next_hop(), T383838next_hop_interface() — read-only, safe

These could be changed to T383838const auto& for efficiency but are not correctness bugs.

In Python, T383838dict[key] = value always overwrites. In C++, T383838std::map::insert({key, value}) is a no-op if the key already exists — it silently discards the new value and returns the old entry.

File: T383838Transport.cpp, path table update code

T282828

Te6edf3_destination_tableTb4b4b4.Te6edf3insertTb4b4b4(Tb4b4b4{Te6edf3destination_hashTb4b4b4, Te6edf3new_destination_entryTb4b4b4}Tb4b4b4)Tb4b4b4;

T8b949e// If destination_hash already exists, the insert does NOTHING.

T8b949e// The old (stale) path entry remains.

Impact: When a destination announces a new path (e.g. it roamed to a different transport node), the path table keeps the old stale entry. Packets continue to be routed to the old path, which may no longer work.

Fix: Erase before insert:

T282828

Te6edf3_destination_tableTb4b4b4.Te6edf3eraseTb4b4b4(Te6edf3destination_hashTb4b4b4)Tb4b4b4;

Te6edf3_destination_tableTb4b4b4.Te6edf3insertTb4b4b4(Tb4b4b4{Te6edf3destination_hashTb4b4b4, Te6edf3new_destination_entryTb4b4b4}Tb4b4b4)Tb4b4b4;

Note: This same pattern (T383838insert without T383838erase) should be audited across ALL map insertions in the codebase. Any map that might receive updated entries for existing keys needs the erase-before-insert pattern, or should use T383838operator[] or T383838insert_or_assign().

File: T383838Transport.cpp

The T383838_boundary_local_addresses set accumulates every local device address seen via LoRa announces. There is no size cap and no eviction mechanism. On a long-running boundary node that sees many transient devices, this grows without bound.

Impact: Slow heap exhaustion over days/weeks of operation. Particularly problematic on ESP32 with limited RAM.

Fix needed: Add a size cap (e.g. 200) with timestamp-based or LRU eviction, similar to how T383838_boundary_mentioned_addresses is capped.

File: T383838Transport.cpp

The T383838_held_announces map stores announces waiting to be retransmitted. There is no size cap. If the retransmit never triggers (e.g. the outbound interface disappears), entries can be orphaned and accumulate indefinitely.

Impact: Slow memory leak, exacerbated on busy networks with many announces.

Fix needed: Add a size cap or timeout-based eviction.

File: T383838Transport.cpp

Status: Fixed (added T383838.erase(iter) call)

Entries in T383838_pending_local_path_requests were inserted but never removed after the path request was fulfilled. Over time the map grew without bound.

File: T383838Transport.cpp

Status: Fixed (added T383838DESTINATION_TIMEOUT-based culling in T383838jobs())

The T383838_path_requests map recorded timestamps of path requests but entries were never removed. Each unique destination hash that triggered a path request stayed in the map forever.

File: T383838Transport.cpp, boundary mode local→backbone forwarding

T282828

Tff7b72else Tb4b4b4{

Te6edf3DEBUGTb4b4b4(Ta5d6ff"Ta5d6ffBOUNDARY: No path to Ta5d6ff" Tff7b72+ Te6edf3packetTb4b4b4.Te6edf3destination_hashTb4b4b4(Tb4b4b4)Tb4b4b4.Te6edf3toHexTb4b4b4(Tb4b4b4) Tff7b72+ Ta5d6ff"Ta5d6ff for local packet. Requesting path.Ta5d6ff"Tb4b4b4)Tb4b4b4;

Te6edf3request_pathTb4b4b4(Te6edf3packetTb4b4b4.Te6edf3destination_hashTb4b4b4(Tb4b4b4)Tb4b4b4)Tb4b4b4;

Tb4b4b4}

Impact: Link data packets are addressed to a T383838link_id (the link's unique identifier), not a destination hash. The T383838link_id will never be found in T383838_destination_table — it's only in T383838_link_table. So every link data packet from a local device triggers a T383838request_path(link_id) call, which broadcasts a PATH REQUEST for a hash that is not any destination.

For a resource transfer with 100 chunks, this sends 100 useless PATH REQUEST broadcasts over LoRa (with no deduplication — T383838request_path() always sends). This wastes radio airtime and can cause congestion-related timeouts on slow LoRa links.

Fix: Check if the destination is a known link_id before requesting a path:

T282828

Tff7b72else Tb4b4b4{

Tff7b72if Tb4b4b4(Te6edf3_link_tableTb4b4b4.Te6edf3findTb4b4b4(Te6edf3packetTb4b4b4.Te6edf3destination_hashTb4b4b4(Tb4b4b4)Tb4b4b4) Tff7b72=Tff7b72= Te6edf3_link_tableTb4b4b4.Te6edf3endTb4b4b4(Tb4b4b4)Tb4b4b4) Tb4b4b4{

Te6edf3DEBUGTb4b4b4(Ta5d6ff"Ta5d6ffBOUNDARY: No path to Ta5d6ff" Tff7b72+ Te6edf3packetTb4b4b4.Te6edf3destination_hashTb4b4b4(Tb4b4b4)Tb4b4b4.Te6edf3toHexTb4b4b4(Tb4b4b4) Tff7b72+ Ta5d6ff"Ta5d6ff for local packet. Requesting path.Ta5d6ff"Tb4b4b4)Tb4b4b4;

Te6edf3request_pathTb4b4b4(Te6edf3packetTb4b4b4.Te6edf3destination_hashTb4b4b4(Tb4b4b4)Tb4b4b4)Tb4b4b4;

Tb4b4b4}

Tb4b4b4}

File: T383838Transport.cpp, inbound transport forwarding (where we are designated next-hop but destination_table lookup fails)

Same pattern: for link data packets with HEADER2/TRANSPORT headers where the transportid matches us, if the destinationhash (which is a linkid) isn't in the destination table, the code requests a path for the link_id — another spurious broadcast.

Fix: Same guard — check T383838_link_table before calling T383838request_path().

Every T383838std::map::insert() call in the codebase should be reviewed. The ones that are intentional "insert-if-not-exists" semantics are fine. The ones ported from Python T383838dict[key] = value (which overwrites) need to use erase+insert or T383838insert_or_assign().

Run:

T282828

grep -n Ta5d6ff"Entry [a-z_]* = .*\.second" Transport.cpp

Any match where the variable is later mutated (assigned to T383838._timestamp, T383838._validated, etc.) is a bug.

Every T383838std::map and T383838std::set in Transport that accumulates entries over time needs:

1. A size cap appropriate for ESP32 memory constraints

2. An eviction strategy (timestamp-based, LRU, or lexicographic)

3. Culling in the T383838jobs() periodic task

File: T383838Transport.cpp, inbound() after packet_filter

Bug: The C++ code unconditionally added every accepted packet's hash to

T383838_packet_hashlist immediately (line ~1505), before link transport or proof

handling ran:

T282828

Te6edf3_packet_hashlistTb4b4b4.Te6edf3insertTb4b4b4(Te6edf3packetTb4b4b4.Te6edf3packet_hashTb4b4b4(Tb4b4b4)Tb4b4b4)Tb4b4b4; T8b949e// Always, immediately

The Python reference implementation (T383838Transport.py lines 1362-1373)

defers insertion for two cases:

1. Packets whose T383838destination_hash is in T383838link_table (link data packets)

2. LRPROOF packets (type=PROOF, context=LRPROOF)

For link data: the hash is added later, inside the link transport

forwarding block, only after a valid outbound direction is confirmed

(T383838Transport.py line 1544).

For LRPROOF: the hash is never added (allowing duplicate proofs to be

processed on multiple interfaces).

Impact: On shared-medium interfaces (e.g. LoRa), a packet belonging to a

link that transports through this node may arrive on the "wrong" interface

first (e.g. received on LoRa before it arrives via TCP backbone). The

premature hash insertion causes the correct arrival to be filtered as a

duplicate for non-resource contexts (DATA ctx=0, LINKIDENTIFY, LRRTT,

LINKCLOSE). Resource contexts (RESOURCE, RESOURCEREQ, RESOURCEPRF)

are unaffected because they bypass the hashlist check in T383838packet_filter.

Fix: Defer hash insertion for link-table and LRPROOF packets, matching

the Python reference implementation. Add T383838_packet_hashlist.insert() inside

the link transport forwarding block after direction is confirmed.